Whereas conventional 2G mobile networks, such as those conforming to the Global System for Mobile Communications (GSM) standards, have provided circuit-switched voice and data services to users' mobile stations (MSs), there is great momentum in the mobile telecommunications industry to deploy packet-switched mobile networks. Packet-switched mobile networks have significant advantages in terms of network and radio resource efficiency and also enable the provision of more advanced user services. With the convergence of fixed and mobile telecommunications, the Internet Protocol (IP), widespread in fixed networks, is the natural choice as the packet routing mechanism for mobile packet networks. Currently IP version 4 (IPv4) is in widespread use in the fixed network domain. However, it is expected gradually to migrate to IP version 6 (IPv6) which offers well-recognised benefits over IPv4, notably in terms of greatly increased address space, more efficient routing, greater scalability, improved security, Quality of Service (QoS) integration, support for multicasting and other features.
A particular example of a mobile packet-switched service currently being deployed is the General Packet Radio Service (GPRS) as implemented in both 2G GSM networks and in 3G Universal Mobile Telecommunications System (UMTS) networks (hereinafter referred to as GPRS networks). It is also expected that non-GPRS wireless access technologies, such as wireless Local Area Network (wLAN), will provide a flexible and cost-effective complement to GPRS for local broadband service access in some areas such as hotspots (conference centres, airports, exhibition centres, etc). wLAN subnetworks may be implemented within the same administrative network domain as GPRS subnetworks, and mobile network operators will want to support mobility of mobile stations between those subnetworks. Furthermore, mobile network operators will want to support roaming of mobile stations between different administrative network domains, which may or may not implement different access technologies.
While GPRS networks, having been designed from the start as mobile networks, have built-in mobility management (for MSs within the GPRS network) and roaming functionality (for MSs roaming between GPRS networks), work has also taken place in the Internet Engineering Task Force (IETF) to support mobility of IP user terminals in general. To this end, the IETF has developed the Mobile IP (MIP) protocols. MIP is designed to support mobility when mobile stations (or mobile nodes (MNs) in MIP terminology) move between IP networks with different subnet prefixes (macro-mobility). For example, MIP may be used to support mobility between a GPRS network and a non-GPRS network such as a wLAN network as well as mobility between two different GPRS networks or subnetworks. Mobile IP is not expected to be used for mobility management within a network or subnetwork (micro-mobility) which is typically managed by access technology specific layer 2 mechanisms such as WCDMA softer/soft handover.
There are two versions of MIP to correspond to the two versions of IP. MIP version 4 (MIPv4) is designed to provide IP address mobility for IP version 4 (IPv4) addresses, whereas the newer MIP version 6 (MIPv6) MIP is designed to provide IP address mobility for IP version 6 (IPv6) addresses. MIPv4 is described in the IETF Request For Comment (RFC) 3344 available at the IETF website http://www.ietf.org/rfc/rfc3344.txt?number=3344. Internet draft MIPv6 is described in the IETF Internet draft “Mobility Support in IPv6” available at the IETF website at http://searchietf.org/internet-drafts/draft-ieft-mobileip-ipv6-20.txt and referenced as draft-ietf-mobileip-ipv6-20.txt.
MIPv4 mobility management is illustrated in FIG. 1. A MN 40 is allocated a home IP address (HAddr) in its Home Network (RN) 42. Routing procedures in the MN ensure that wherever the MN is within the HN, an IP packet sent from a Correspondent Node (CN) 46 will reach the MN. However, when the MN roams to a foreign network (FN) 44, IP packets addressed to its HAddr will need to be routed to its new location in the FN. In MIPv4, a router 48 in the EN known as the Home Agent (HA) is used to act as a packet forwarding service on behalf of the MN when it is away from home. In a first working mode of MIPv4 (known as FA-CoA mode), when arriving in the FN, the MN is allocated a Care of Address (CoA) by a router 50 in the FN known as the Foreign Agent (FA). Due to perceived limitations of IPv4 address space, it is envisaged that more than one MN may share the same CoA. After allocation of the CoA, the FA 50 sends a binding update to the HA to register the CoA. More specifically, the binding update informs the HA of the association (or binding) between the HAddr and CoA of the MN. Thereafter, when the CN sends a packet to the HAddx of the MN in its EN (case 1), the packet is intercepted by the HA and tunnelled to the FA in the FN via tunnel 52 on the basis of the CoA.
Tunneling involves encapsulating a first data packet (with a header and a payload) as the payload of a second data packet having a new header indicating, as its source and destination addresses, the start and end points of the tunnel, and transferring the second data packet as normal to the tunnel endpoint where it is decapsulated to obtain the first packet. After decapsulation, the tunnel end point, the FA, routes the original packet to the MN using routing procedures in the FN. In MIP, tunnelling involves IP in IP encapsulation using the IETF Request For Comment (RFC) 2003. Thus in MIPv4, an IPv4 packet is tunnelled by encapsulating it within another IPv4 packet.
As an optional procedure in MIPv4, the HA may send a binding update to the CN to register the CoA of the MN. More specifically, the binding update informs the CN of the association (or binding) between the HAddr and CoA of the MN. Thereafter, the CN may address packets directly to the MN at its current CoA, rather than indirectly via its HAddr (case 2), and these packets are received by the FA in the FN and routed to the MN using routing procedures in the FN. This is known as route optimisation since it avoids potentially inefficient triangular routing via the HA which in general will not be on an efficient routing path between the CN and the FA.
In a second optional working mode of MIPv4 (known as CoCoA mode) there is no sharing of CoAs by MNs away from their home network and no FA is used. The MN is allocated a unique CoA, known as a co-located CoA (CoCoA). In this working mode, the MN must itself send a binding update to its HA to register its newly allocated CoCoA. Thereafter, packets sent by a CN and addressed to the MN at its HAddr are tunnelled from the HA directly to the MN. As with FA-CoA mode, as an optional procedure in CoCoA mode, the MN may also send a binding update to a CN to register its CoCoA. Thereafter, packets may be sent by the CN directly to the MN at its CoCoA.
MIPv6 mobility management is illustrated in FIG. 2. Two notable differences of MIPv6 over MIPv4 are as follows. Firstly, due to the greatly increased address space in IPv6, CoAs allocated to a MN in a FN are never shared (ie they correspond to the optional CoCoA in MIPv4). Secondly, as a result, there is no need to deploy a FA in the FN. Referring to FIG. 2, with MIPv6, when a MN 40 moves from its MN 42 to a FN 44, it is allocated a unique CoA and sends a binding update to its HA 48 in its HN to register the CoA. Packets from a CN 46 addressed to the HAddr are intercepted by the HA 48 (case 1) and tunnelled to the CoA via tunnel 54. This tunnelling may be achieved using IPv6 Generic Packet Tunnelling Mechanism described in IETF RFC 2473. However, in MIPv6, route optimisation is not an option but a fundamental part of the protocol and, in general, the MN (not the HA as in MIPv4) should send a binding update to the CN so that it may address packets directly to the MN at its CoA (case 2). When a MN receives a packet tunnelled from a CN via the MN's HA, it may take this as an indication that the CN has no binding for the MN and initiate a CN binding update.
There are a number of problems which arise as a result of the binding update procedures specified in MIPv4 and MIPv6. The problems arise in connection with both binding updates to the HA (let us call these Home Binding Updates (HBUs)) and binding updates to a CN (let us call these Correspondent Binding Updates (CBUs)). One problem is resource utilization in the FN. In MIPv4 CoCoA mode and in MIPv6, the MN performs HBU and CBU procedures which utilise various resources of the FN, including valuable radio resources. With HBUs, this problem is exacerbated by the fact that HBUs will need to be sent periodically, even when the MN is not in use but roaming in a FN over extended periods of time. Resource utilization may also be a problem in MIPv4 FA-CoA mode where the FA performs the HBU.
Another problem with HBU and CBU procedure is security. The issuing of false binding updates to the HA or CN of a MN can lead to security attacks including denial-of-service, confidentiality, man-in-the-middle, hijacking and impersonation attacks (see MIPv6 draft specification section 14, for example). Thus, complex security procedures are mandated in the MIP specifications (see MIPv6 draft specification section 5, for example). These security procedures are slow and costly in terms of processing requirements at the HA, CN and at the MN. This can also adversely effect battery lifetime at the MN and CN.
Another problem is that any delay in HBU procedures can lead to misdirecting of packets to an old CoA, caching of packets at the HA or, worse still, loss of those packets. Similarly, any delay in CBU procedures can lead to misdirecting of packets to an old CoA, triangular routing via the HA or, worse still, loss of those packets. These effects lead to decreased performance at the HA, unnecessary loading of routers through which misdirected or non route optimised packets are sent, and possible disruption to communication sessions between the MN and CN.